# Оптимизация количества тестирования
## Описание
Оптимизация тестирования — это выработка такой стратегии тестирования, которая позволит минимальными средствами снижать критичные риски по продукту.

## Почему ветка важна?
Менеджер:
- Оптимизирует штат тестировщиков
- Влияет на скорость доставки фичи до боя
- Понимает, почему тестирование проводится так и занимает столько времени

Разработчик:
- Понимает, что делают тестировщики  и что от них ждать
- Влияет на тестирование — от unit-тестов до testability

Тестировщик:
- Понимает, что тестировать и насколько подробно
- Чувствует меньше давления, что тестирование замедляет процесс работы команды
- Участвует в тестировании вместе с командой

## Что будет, если её не делать?
- Команда не будет понимать, сколько времени и сколько тестировщиков надо, чтобы снижать критичные риски в продукте:
  - Риск "раздувания" штата тестировщиков
  - Сложно планировать сроки, когда фича будет на бою
  - Непонятно насколько эффективно тестирование

## На кого может быть делегирована?
На процессных менеджеров или Scrum-мастеров. Частично делегируется на тестировщиков.

### Примеры плохого поведения
- При оптимизации тестирования не учитываются краткосрочные и долгосрочные риски
- За оптимизацию отвечает только отдел тестирования
- Обвинение тестировщиков, что они медленно делают работу, вместо исследования процесса
- Команда не понимает, что тестирование делает в текущем процессе
- Оптимизация фокусируется только на скорости тестирования

### Примеры хорошего поведения
- Оптимизация начинается с того, что команда и бизнес понимают, зачем им тестирование
- Оптимизация тестирования затрагивает весь процесс разработки — от постановки задач до эксплуатации
- Команда понимает как работать с дополнительными рисками, которые возникают при оптимизации тестирования

## Способы прокачки
### Практика

Прежде чем оптимизировать то тестирование, которое у вас уже есть, или строить новый процесс, поймите зачем вам нужно тестирование и нужно ли на самом деле?

Начните с того, что подумайте о рисках для вашего продукта. Опирайтесь на функциональные и [нефункциональные](/roles/technical-lead/product-quality/nfr) требования. Например:
- Что будет, если вы выпустите продукт с багом?
  - Насколько много ваших пользователей это затронет?
  - Насколько сложно будет пользоваться продуктом с этим багом? Будет ли это вообще возможно?
- Что будет, если ваш продукт будет сложно поддерживать?
- Что будет, если ваш продукт будет уязвим для взлома?
- Что будет, если в вашем продукте будет сложно разобраться пользователям?
- Как быстро вы поймёте, что у вас баг на бою и оцените, насколько он критичный?
- Как быстро вы исправите баг, который нашли на бою?

Чтобы снизить эти риски, используйте три процесса — тестирование, проверку и мониторинг.

Тестирование — это процесс исследования и изучения продукта. Когда вы тестируете, вы узнаете как программа работает на самом деле, ну или не работает. Тестировщики не просто проверяют ТЗ, а используют всю свою креативность, опыт и знание продукта. Тестирование нельзя автоматизировать, как нельзя автоматизировать человеческое мышление (ну по крайней мере пока).

Проверка — подтверждение существующих ожиданий. Когда вы что-то проверяете — точно знаете, что должны получить, и убеждаетесь, что 2+2 все так же равно 4. Многие проверки можно эффективно автоматизировать.

Майкл Болтон сравнивает проверки с компиляцией программы, а тестирование — с программированием. Первый процесс формализован и проводится автоматически, для второго нужны люди и их знания и навыки.

Более подробно про тестирование и проверки — [оригинал](https://www.developsense.com/blog/2009/08/testing-vs-checking/), [перевод](http://qastugama.blogspot.com/2013/09/blog-post_6.html).

Мониторинг — процесс выявления проблем, которые возникают на бою у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.

Используйте эти процессы все сразу или частично, в зависимости от ваших рисков.

Например, вы не прорабатываете детально ТЗ и рискуете не учесть что-то важное. Можно:
- снизить риски за счёт тестирования — переложить на него тестирование требований, хранение знаний и выяснение как все работает на самом деле
- принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть на бою.

Если же вы решили прописать все в ТЗ, то можно меньше тестировать и больше отдать на проверки — как ручные и автоматические. Такое часто бывает в заказной разработке на государственных проектах — утверждённое ТЗ и программа приёмо-сдаточных испытаний.

Если вы знаете, что определённые проблемы будут критичны для вашего бизнеса, то нужно тщательно тестировать и проверять места, в которых они могут быть. Например, важно, чтобы пользователи могли оплатить ваш продукт. Или баги могут подорвать доверие к вашему продукту, например если вы разрабатываете платёжную систему. Важно помнить, что нельзя протестировать абсолютно все и на 100% знать, что все работает. Но можно снизить риски.

Когда вы разрабатываете MVP — вам надо убедиться, что ваш продукт жизнеспособен. А значит можно ограничиться минимальными проверками.

На этой базе составьте стратегию тестирования. Каждый человек в команде должен понимать, что мы тестируем, где и зачем.

### Видео
- [Как Atlassian ускорял тестирование](https://www.atlassian.com/agile/software-development/qa-at-speed)
- [Тестирование через мониторинг](https://www.highload.ru/2016/abstracts/2346.html)
- [Автотестеры не нужны, или Эволюция применения тестов](https://www.youtube.com/watch?v=jviyM-2D0F8&l)
- [Testing is dead](https://www.youtube.com/watch?v=X1jWe5rOu3g)

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp).

## Теория
### Статьи
- Почему тестирование занимает столько времени — [часть 1](https://www.developsense.com/blog/2009/11/why-is-testing-taking-so-long-part-1), [часть 2](https://www.developsense.com/blog/2009/11/what-does-testing-take-so-long-part-2), <a href="https://software-testing.ru/library/testing/general-testing/911-why-is-testing-taking-so-long" data-proofer-ignore>перевод</a>
- Нужно ли вам больше тестировщиков? — [оригинал](https://www.developsense.com/blog/2007/04/do-you-need-more-testers-context-driven), [перевод](http://goblingame.blogspot.com/2011/09/blog-post.html)
- [A new model for test strategies… (An update to the Heuristic Test Strategy Model)](https://danashby.co.uk/2017/12/13/a-new-model-for-test-strategies/)

### Подкасты
- [Радио QA. Стратегия тестирования](http://radio-qa.com/vypusk-10-strategiya-testirovaniya/)
